We want to permanently move a project from one server to another. On the new server, everything will be managed by new users.
As I understand it, the right way to do this is to create a partition definition with all the modules that we want to move, then export it and import it onto the new server.
Reading the administrator guide, I have a few questions:
-
Am I correct in thinking that partitions are the way to go?
-
How do I ensure that users will be able to access the modules after import? The manual seems to say that there will be restrictions on the imported data, which cannot be removed even by super users.
-
Is there some way to (do I want to?) "cut the link" and make the new server forget that the imported modules are part of an import?
-
Considering that the group of users on the new server is completely disjoint from the users on the old server, will there be any other issues regarding pemissions, that I should be aware of?
-
Is there an easy way to select all modules, linksets etc. in a project for inclusion in the partition? We're moving several hundred of these, spread across many folders/sub projects. Selecting each one separately is annoying and error prone.
Thanks for any wisdom anyone may impart.
SystemAdmin - Fri Jan 07 13:48:37 EST 2011 |
|
Re: Completely move a project to different server SystemAdmin - Fri Jan 07 18:56:11 EST 2011
I think the best approach to move a Project from one DOORS DB to another DB is through Archive & Restore feature in the DOORS client. You can Archive the Project (File > Archive) in the Source DOORS DB and Restore (File > Restore > Project) in the target DOORS DB.
Though the entire data in the project is moved to the Target DOORS DB, this has the following limitations.
1. The access rights of all the items in the Project will be reset in the Target DOORS DB (i.e., Everyone will have full access).
2. All links between modules present in this project (to be archived) and modules which do not fall under this project will be lost. However, links between modules within this Project (to be archived) will be retained and brought over to the new DB, provided that the all associated link modules do fall under this Project (to be archived).
Hope it helps.
|
|
Re: Completely move a project to different server PDU - Mon Jan 10 02:00:00 EST 2011 SystemAdmin - Fri Jan 07 18:56:11 EST 2011
I think the best approach to move a Project from one DOORS DB to another DB is through Archive & Restore feature in the DOORS client. You can Archive the Project (File > Archive) in the Source DOORS DB and Restore (File > Restore > Project) in the target DOORS DB.
Though the entire data in the project is moved to the Target DOORS DB, this has the following limitations.
1. The access rights of all the items in the Project will be reset in the Target DOORS DB (i.e., Everyone will have full access).
2. All links between modules present in this project (to be archived) and modules which do not fall under this project will be lost. However, links between modules within this Project (to be archived) will be retained and brought over to the new DB, provided that the all associated link modules do fall under this Project (to be archived).
Hope it helps.
Hi,
other limitation :
for example if you have DXL attribut generated from Layout DXL generated by Analysis/Wizard/.. specific module, your code don't work in this new server :
Modules, as all objects, are identified by an unique identifier in the data base. When you restore your projetc in a new data base, this identifier can not be the same.
So, you need check your codes.
I don't know if there is a better solution.
Pierre
|
|
Re: Completely move a project to different server llandale - Mon Jan 10 10:25:01 EST 2011
Partition/Rejoin is for when you figure to temporarily send some other database some data, let them edit it, figuring they will send it back. If you figure to just send and go about your merry way, Archive/Restore is far simpler. Understand, however, that doing so causes everthing in the restored proejct to become 'inherited' and you'll need to reset your access rights, which can be quite a pain.
In this case, however, since you want the same users to have access to the new database and identical access to the Project, you should just copy the entire database.
[1] Make sure the new database works and clients can access it.
[2] Shut down both databaser services.
[3] Delete the entire target database
[4] Copy the entire home database and move the file folders to the new.
[5] Start both DB services and insure you can access both databases. Be advised that the new database will have the same users as the old; specifically the original new Adminstrator password will be lost and the target database password will be the same as the home.
[6] In the home database, delete and purge the project in question.
[7] In the target database, delete and purge all the OTHER projects.
You may want to make sure the project in question has no links or to anything outside the project.
If you do not want the away database folks to ever even SEE your other projects, then you'll need to set up a temporary database simbling to the home, copy it there, delete and purge all other projects, then send them that database's file folders.
|
|